Access control method, and associated lock device and administration server

ABSTRACT

An access control method is disclosed in which a lock device provides conditional access to a protected environment by short-range wireless communication with a key device having a key device identifier (KD_ID). In the method, the lock device requests the key device to provide a challenge response to a challenge generated by the lock device based on a challenge code kept by the lock device. The lock device receives the challenge response from the key device. The challenge response is generated by a remote administration server and is based on the key device identifier of the key device. The generated response is sent to the key device and forwarded from the key device to the lock device. The lock device then verifies the received challenge response based on the challenge code and on the key device identifier of the key device.

FIELD OF THE INVENTION

The present invention relates to access control, and more particularlyto an access control method in which a lock device provides conditionalaccess to a protected environment by short-range wireless communicationwith a key device having a key device identifier. The invention alsorelates to a lock device for use in an access control system whichinvolves a plurality of lock devices, a plurality of key devices, eachkey device having a key device identifier, and an administration server.In addition, the invention relates to an administration server having anassociated system database which defines the conditions under whichindividual ones of the key devices may be granted access to protectedenvironments by individual ones of the lock devices.

BACKGROUND OF THE INVENTION

Access control methods and systems are previously known in whichelectronic lock devices are installed at doors, gates, etc., so as toprovide conditional access to protected environments. A user that seeksaccess to such a protected environment will use an electronic key devicewhich will communicate with the lock device in question. Based on thiscommunication, the lock device will decide whether or not to allow theuser to access the protected environment, for instance by controlling anelectro-mechanical lock which is included in or coupled to the lockdevice.

Generally, there are two distinctly different categories of accesscontrol systems. In the first category, the key device acts as anintermediate device to allow communication between the lock device and aremote central server. Such communication may take place over existingwide-area data and/or telecommunication networks. The outcome of thiscommunication will determine whether or not the key device—and the usercarrying it—shall be granted access to the environment protected by thelock device at any given moment.

WO 2006/098690 discloses an access control system of a second category.In WO 2006/098690, the electronic key devices are capable of short-rangewireless data communication with the lock devices. Each key device has akey device identifier which is used for the short-range wireless datacommunication, and the lock device is configured to performauthentication of an appearing key device by detecting the key deviceidentifier of the key device and using the detected key deviceidentifier, together with some other parameters, to determine whetheraccess shall be granted. Each lock device is a stand-alone device withits own internal power source and requires no wiring to itssurroundings. When a key device approaches and seeks access, the lockdevice will communicate with the key device using short-range wirelessdata communication, but it will typically not need any furthercommunication with other, more remote elements in the system, such as acentral server. In order to operate autonomously, the lock device useslocal lock access data which is stored within the lock device anddefines the key device identifiers of key devices which are allowed toaccess the protected environment. In one embodiment, the key devices aremobile terminals or other similar types of portable communicationdevices being equipped with short-range wireless data communicationinterfaces in the form of Bluetooth® transceivers. Hence, the key deviceidentifier of each key device is the unique Bluetooth® address assignedto the Bluetooth® transceiver in the key device.

In an access control system of the above second category, where the lockdevices operate autonomously on locally stored lock access data, therewill be an issue when it comes to providing the lock access data intothe lock devices. Initially, when a new lock device is to be installedat the intended protected environment, the lock device may be programmedwith certain initial lock access data, either during the manufacturingprocedure, or by service personnel before or during the actualinstallation. This initial lock access data will then define anarbitrary number of key devices which are authorized to access theprotected environment, these key devices being identified in the lockaccess data by their respective key device identifier (Bluetooth®address).

Once installation is completed, the autonomously operating lock devicehas no other contact with the surroundings, except when an appearing keydevice seeks access to the environment protected by the lock device. Theaccess control system of WO 2006/098690 is therefore configured toexchange various data between key device and lock device, once the keydevice has been successfully authorized and a bi-directional Bluetooth®link has been established between the devices. The types of dataexchanged include log file and status data recorded by the lock deviceregarding for instance previous attempts by key devices to access theenvironment protected, as well as updated lock access data intended toreplace or upgrade the existing lock access data in the lock device.Such updated lock access data will have been generated by anadministrator at a remote administration server and sent in advance tothe key device over one or more existing communication networks such asthe Internet and/or a telecommunications network. Upon receipt, the keydevice will have buffered the updated lock access data, waiting for anopportunity when the user of the key device approaches the lock devicein question to forward the updated lock access data to the lock device.

In this way, service personnel do not have to visit the premises wherethe lock device is installed in order to update the lock access data.Instead, updated lock access data may be sent via the key device overexisting communication networks, as mentioned above. However, thisrequires that the key device which visits the lock device is indeedauthorized to access the protected environment; otherwise there will beno Bluetooth® link established between the devices and, consequently, noopportunity for the key device to forward the updated lock access datato the lock device. In turn, in order to be considered as authorized bythe lock device, the key device identifier of the key device must beincluded in the current lock access data in the lock device. In otherwords, the key device must already be known to the lock device.Actually, in real-world implementations, not all key devices aretypically allowed to bring updated lock access data to lock devices.Rather, a subset of particularly trusted key devices is designated asambassadors; only these will be allowed to bring updated lock accessdata to the lock devices. Ambassador key devices may for instance bepossessed and used by managers, security personnel or other trustedusers in the access control system.

As time passes, any real-world implementation of an access controlsystem will experience needs to add new users/key devices to the system,to change which particular key devices that shall be able to access eachparticular lock device, to remove users/key devices from the system,etc. These needs will be all the more frequent and complicated, thebigger and more complex the access control system grows. This will beconsidered in more detail in a later section of this document withreference to FIG. 1.

One particularly problematic situation which needs to be handled is whena whole set of key devices, which has hitherto been defined asauthorized according to the current lock access data in one or more lockdevices, no longer shall be authorized but instead be replaced by a newgroup of key devices. If none of the key devices in the new group ispreviously known to a lock device, then that lock device will not beprepared to communicate with any such unknown key device and willtherefore not be able to receive the updated lock access data.

Another particularly problematic situation is when a new key device isto be added to the list of authorized key devices for a particular lockdevice, but that lock device is only visited by an ambassador key deviceat infrequent occasions. This may mean that the new key device's accessto the particular lock device is considerably delayed by as much as aweek, month or even more.

Generally, the invention seeks to find a trade-off between two opposinginterests—to allow for a flexible way of distributing sets of updatedlock access data to all relevant lock devices, while maintainingsecurity at an acceptable level.

SUMMARY OF THE INVENTION

In view of the above, an objective of the invention is to solve or atleast reduce the problems discussed above.

On a conceptual level, the invention is based on the inventive insightthat autonomously operating lock devices (i.e. an access control systemof the above-mentioned second category) can be provided with additionalfunctionality for requesting a key device to provide a response to achallenge made by the lock device. The challenge shall be based on achallenge code generated and/or stored locally in the lock device, andthe response to the challenge shall be created by a remoteadministration server and shall be based on information that serves toidentify the key device.

In a way, the present invention can be seen to be based upon a hybridbetween the two different categories of access control systems referredto above.

In view of the above, a first aspect of the present invention thereforeis an access control method in which a lock device provides conditionalaccess to a protected environment by short-range wireless communicationwith a key device having a key device identifier, the method involving:

the lock device requesting the key device to provide a challengeresponse to a challenge generated by the lock device based on achallenge code kept by the lock device;

the lock device receiving the challenge response from the key device,wherein the challenge response is generated by a remote administrationserver and is based on the key device identifier of said key device, andwherein the generated response is sent to the key device and forwardedfrom the key device to the lock device; and

the lock device verifying the received challenge response based on thechallenge code and on the key device identifier of said key device.

Advantageously, the remote administration server generates the challengeresponse as a function of a copy of said key device identifier kept bythe administration server, and the lock device detects the key deviceidentifier during the short-range wireless communication with the keydevice and uses the detected key device identifier for verifying thereceived challenge response.

In one or more embodiments, the lock device generates the challenge byencrypting the challenge code using a key which is based on at least oneof a serial number and a lock device identifier of said lock device.

In one or more embodiments, the administration server:

receives the challenge from the key device;

determines, from information received from the key device, the lockdevice from which the challenge originated;

searches a system database associated with the administration server toretrieve at least one of a serial number and a lock device identifier ofthe lock device from which the challenge originated; and

decrypts the received challenge to derive the challenge code using a keywhich is based on the retrieved serial number and/or lock deviceidentifier.

In this or other embodiment(s), the administration server further:

retrieves the copy of said key device identifier by searching the systemdatabase using information received from the key device; and

generates the challenge response based on the derived challenge code andthe retrieved copy of said key device identifier.

In this or other embodiment(s), the administration server further:

encrypts the challenge response by using a key which is based on theretrieved serial number and/or lock device identifier; and

sends the encrypted challenge response to the key device.

In this or other embodiments, the lock device:

receives the encrypted challenge response from the key device; and

decrypts the received encrypted challenge response by using a key whichis based on at least one of the lock device serial number and the lockdevice identifier of said lock device.

The challenge response generated by the remote administration server mayinclude usage restriction data, defining at least one of an expirationdate/time for the challenge response, and a maximum usage limit for thechallenge response.

Further, the challenge response generated by the remote administrationserver may include a part which is readable by the key device and whichdefines an expiration date/time for the challenge response, wherein thekey device will prevent forwarding of the challenge response to the lockdevice if the expiration date/time has lapsed.

In one or more embodiments, where the lock device has a memory forstoring lock access data, said lock access data including key deviceidentifiers of key devices which are allowed to access the environmentprotected by the lock device, the method comprises the initial steps,performed by the lock device, of:

when the key device approaches the lock device and seeks access,detecting the key device identifier for the key device;

checking if the detected key device identifier matches the lock accessdata stored in the memory of the lock device; and

if no match is found in the checking step, generating said challenge andsending it to the key device.

Advantageously, the short-range wireless communication is Bluetooth®communication; wherein the lock device may detect the key deviceidentifier by reading a Bluetooth® address assigned to a Bluetooth®transceiver used by the key device for the Bluetooth® communication withthe lock device.

Embodiments of the method may operate in an “Online” mode, which meansthat the generated challenge is sent from the lock device to the keydevice when the latter seeks access but is denied this because there isno key device identifier representing that key device in the lockdevice's memory (i.e., the key device is unknown to the lock device).Thus, in Online mode, the generated challenge is sent from the lockdevice to the key device using short-range wireless communication. Thekey device then forwards the generated challenge to the administrationserver over an available communication channel, which may be apacket-based or circuit-switched communication channel over a mobiletelecommunications network such as GSM, UMTS, LTE, D-AMPS, CDMA2000,FOMA or TD-SCDMA. Alternatively or additionally, the communicationchannel may comply with a wireless data communication standard such asWLAN (Wireless Local Area Network).

Alternatively or additionally, embodiments of the method may operate inan “Offline” mode. In Offline mode, a challenge code in insteadtransferred in advance from the lock device to the administrationserver. This may for instance occur in an initial batch of pre-generatedchallenge codes generated in or for the lock device already at the timeof manufacturing, assembling or installation, or in a subsequent batchof challenge codes which are generated by the lock device, when theinitial batch has run out, and communicated to the administration serverby way of another, trusted and allowed key device when it seeks and getsaccess at the lock device.

Thus, in Offline mode, the lock device in advance generates one or morechallenge codes, stores the challenge code(s) in local memory, andcommunicates the challenge code(s) to the administration server forstorage in a system database; the key device in advance requests andreceives a pre-generated challenge response from the administrationserver, and stores the received pre-generated challenge response inlocal memory;

when generating the requested pre-generated challenge response to besent to the key device, the administration server retrieves and uses anyone of the challenge code(s) of the lock device from the systemdatabase;

when the key device approaches the lock device and seeks access, and isrequested by the lock device to provide a challenge response, the keydevice responds by retrieving the pre-generated challenge response fromlocal memory, and sending it to the lock device.

In Offline mode, the lock device may verify the received challengeresponse by producing a candidate challenge response from each challengecode stored in its local memory and the key device identifier of saidkey device, and matching the received challenge response against allproduced candidate challenge responses.

Advantageously, the Online and Offline modes may be used in the sameembodiment where the lock device, key device and administration serverare capable of operating in the Online mode or in the Offline mode,depending on whether or not the key device can access the administrationserver at the moment when it seeks access to the lock device.

Further features of the method according to the first aspect of theinvention are defined in the attached dependent claims.

A second aspect of the present invention is a lock device for use in anaccess control system which involves a plurality of lock devices, aplurality of key devices, each key device having a key deviceidentifier, and an administration server having an associated systemdatabase which defines the conditions under which individual ones of thekey devices may be granted access to protected environments byindividual ones of the lock devices. The lock device has:

a transceiver for short-range wireless communication with a key deviceamong said plurality of key devices;

a memory;

means for detecting the key device identifier of said key device duringthe short-range wireless communication with the key device;

means for generating a challenge code to be stored in said memory;

means for generating a challenge based on said challenge code;

means for causing said transceiver to send the generated challenge tosaid key device;

means for receiving a challenge response from the key device, whereinthe challenge response originates from the administration server;

means for verifying the received challenge response based on thechallenge code in said memory and on the detected key device identifierof said key device; and

means for determining whether conditional access may be given to the keydevice based on an output from said means for verifying.

In addition, the second aspect of the present invention may comprisemeans or other structural elements capable of performing any of the lockdevice functions referred to above for the method according to the firstaspect.

A third aspect of the present invention is an administration server foruse in an access control system which furthermore includes a pluralityof lock devices and a plurality of key devices, each key device having akey device identifier. The administration server has:

a system database which is associated with the administration server,wherein the system database defines the conditions under whichindividual ones of the key devices may be granted access to protectedenvironments by individual ones of the lock devices;

means for receiving a challenge from a key device among said pluralityof key devices over a communication network, wherein the challengeoriginates from a lock device, among said plurality of lock devices, towhich the key device has sought access;

means for retrieving a copy of the key device identifier of said keydevice by searching the system database using information received fromthe key device; means for deriving a challenge code from the receivedchallenge;

means for generating a challenge response based on the derived challengecode and the retrieved copy of the key device identifier; and

means for sending the generated challenge response to said key deviceover said communication network.

In addition, the third aspect of the present invention may comprisemeans or other structural elements capable of performing any of theadministration server functions referred to above for the methodaccording to the first aspect.

Other objectives, features and advantages of the present invention willappear from the following detailed disclosure as well as from thedrawings.

Generally, all terms used in the claims are to be interpreted accordingto their ordinary meaning in the technical field, unless explicitlydefined otherwise herein. All references to “a/an/the [element, device,component, means, step, etc]” are to be interpreted openly as referringto at least one instance of said element, device, component, means,step, etc., unless explicitly stated otherwise. The steps of any methoddisclosed herein do not have to be performed in the exact orderdisclosed, unless explicitly stated.

BRIEF DESCRIPTION OF THE DRAWINGS

The above, as well as additional objectives, features and advantages ofthe present invention, will be better understood through the followingillustrative and non-limiting detailed description of embodiments of thepresent invention, reference being made to the appended drawings.

FIG. 1 is a schematic view of an access control system in whichembodiments of the present invention may be exercised.

FIG. 2 illustrates an access control method which may be performed inthe access control system of FIG. 1.

FIG. 3 a is a schematic flowchart of an access control method accordingto one embodiment, operating in Online mode.

FIG. 3 b is a schematic flowchart of an access control method accordingto one embodiment, operating in Offline mode.

FIG. 4 is a schematic block diagram of a key device which may interactwith a lock device in the access control system of FIG. 1.

FIG. 5 is a schematic block diagram of a lock device according to oneembodiment.

DETAILED DESCRIPTION OF EMBODIMENTS

FIG. 1 illustrates, in a schematic and simplified form, the layout of anaccess control system for elderly care. A first team of caregiverpersonnel 2 is responsible for the elderly care of a first group ofcaretakers, all living in rooms or apartments covered by respectivefront doors 50 ₁-50 _(n). Lock devices 40 ₁-40 _(n) are installed on therespective front doors 50 ₁-50 _(n) and serve as gateways to therespective protected environment (i.e. room or apartment) behind eachdoor. A first pool of key devices 1 ₁-1 _(m) is available to the firstteam of caregiver personnel 2. The key devices 1 ₁-1 _(m) may be mobileterminals. Each lock device 40 ₁-40 _(n) contains lock access data whichincludes the key device identifiers of the key devices 1 ₁-1 _(m) whichare allowed to access the lock device in question.

When a user in the first team starts his shift, he will check out one ofthe key devices 1 ₁-1 _(m) from a caregiver central, for instance keydevice 1 ₁. During his shift, he will use key device 1 ₁ to gain accessto various ones of the front doors 50 ₁-50 _(n) to provide the carerequired by the respective caretakers. This access will be provided byway of Bluetooth® communication between key device and lock device, asindicated at 14 in FIG. 1. Therefore, the key device identifiersmentioned above may advantageously be represented by the uniqueBluetooth® addresses assigned to the Bluetooth® transceivers in therespective key devices.

At the end of his shift, the user will again check in and return the keydevice 1 ₁ to the caregiver central. In addition or alternatively, someor all members of the first team of caregiver personnel 2 may use theirown mobile terminals as key devices. Not all key devices or members ofthe first team of caregiver personnel 2 may be authorized to access alldoors, and they need not all have the same level of authorization interms of times and/or dates when access is allowed.

The access control system of FIG. 1 further involves a second team ofcaregiver personnel 2′ responsible for serving a second group ofcaretakers, the rooms or apartments of which have respective front doors50′₁-50′_(n) to which lock devices 40′₁-40′_(n) are installed. A secondpool of key devices is available to the second team of caregiverpersonnel 2′. Of course, the access control system may in realityinclude additional teams of caregiver personnel, additional groups ofcaretakers, additional front doors, additional lock devices, andadditional pools of key devices.

In addition, security personnel 2″ with key devices 1″₁-1″₂ are includedin the system. Whereas the key devices 1 ₁-1 _(m), of the first andsecond teams 2, 2′ will be used by a relatively large number ofcaregiver persons to access a relatively small number of lockdevices/doors at relatively frequent occasions, the situation is theopposite for the key devices 1″₁-1″₂ of the security personnel 2″. Thesekey devices will be used by a limited number of persons (such as nursesor guards) at rare occasions, but they nevertheless need to be able toaccess a very large number of lock devices/doors—or even all lockdevices/doors that are included in the access control system.

For enhanced security, each key device runs an access control softwareapplication in which the user must log on. Also, all communications withthe lock devices are encrypted. Further, not all users/key devices areallowed to bring updated lock access data to the lock devices. Rather,in the embodiment of FIG. 1, a subset of particularly trusted users/keydevices are designated as ambassadors; only these will be allowed tobring updated lock access data to the lock devices.

Each team of caregiver personnel 2, 2′ may be sub-divided intosub-groups, for instance a day shift, an evening shift and a nightshift. Also, an individual user may act in or for both teams 2 and 2′(for instance to serve as back-up in situations of sickness, parentalleave or during popular holiday periods), therefore having a need to usehis key device for accessing lock devices both in the first group ofcaretakers and in the second group of caretakers. This is illustrated inFIG. 1 for key device 1 _(m), which will access not only lock device 40_(m) in the first group of caretakers, but also lock device 40′₁ in thesecond group of caretakers (see arrow 14 a).

Because of the complex situation in the access control system, it isapparent that given the very large number of key devices and lockdevices involved, it is a difficult and complex problem to keep the lockaccess data in the various lock devices appropriately updated to reflectchanges among the users (caregiver personnel and security personnel), sothat, in each given situation, a certain lock devices makes a correctdecision as to whether or not a user of a certain key device shall begranted access.

FIGS. 2 and 3 a-3 b illustrate how the invention provides a solution tothis difficult and complex problem, for the embodiment shown in FIG. 1.In FIG. 2, it is assumed that one of the key devices 1 ₁-1 _(m),1′₁-1′_(m) approaches one of the lock devices 40 ₁-40 _(n), 40′₁-40′_(n)in step 210. This individual key device is referred to as key device, orKD, 1 in the following, and the main components of the key device 1 areshown in FIG. 4. The corresponding individual lock device is referred toas lock device, or LD, 40, and its main components are shown in FIG. 5.The individual caregiver person that uses the key device 1 is referredto as user 2. At some earlier point in time, the key device 1 may havereceived updated lock access data (ULAD) 456 in a step 200 from theadministration server 100 in FIG. 1.

In the embodiment disclosed in FIG. 4, the key device 1 is a mobileterminal, e.g. a cellular telephone, personal digital assistant (PDA),smart phone, etc., which is capable of communicating with atelecommunications system. Thus, the user 2 may use the key device 1 forvarious telecommunication services, such as voice calls, Internetbrowsing, video calls, data calls, facsimile transmissions, still imagetransmissions, video transmissions, electronic messaging, ande-commerce. Generally, these telecommunication services are not centralwithin the context of the present invention; there are no limitations toany particular set of services in this respect. Therefore, onlycomponents which are somehow pertinent to the inventive functionalityare shown in FIG. 4.

As seen in FIG. 4, the key device 1 has a network interface 430 forconnecting to the Internet/telecommunications network(s) 104. Thenetwork interface 430 may comply with any commercially available mobiletelecommunications standard, including but not limited to GSM, UMTS,LTE, D-AMPS, CDMA2000, FOMA and TD-SCDMA. Alternatively or additionally,the network interface 430 may comply with a wireless data communicationstandard such as WLAN (Wireless Local Area Network).

The key device 1 also has a man-to-machine interface (MMI), or userinterface (UI) 420, which may include a display 422 and a set of keys424 or other input device, as well as other known UI elements like aspeaker and a microphone. The user 2 may control the operation of, andexchange data with, the key device 1 over the user interface 420.

Further, the key device 1 has an interface 440 for short-range wirelessdata communication. In the disclosed embodiment of FIG. 4, the interface440 comprises a Bluetooth® transceiver, by means which the key device 1can communicate with, for instance, the lock device 40 over theBluetooth® link 14. The Bluetooth® transceiver is assigned a uniqueBluetooth® address KD_ID, the meaning of which has already beenexplained above. Alternatively or additionally, the interface 440 mayfor instance comprise transceiver components for IrDA (Infrared DataAssociation), WLAN or NFC (Near Field Communication).

A processing unit 410 is overall responsible for the operation andcontrol of the different components of the key device 1. The processingunit 410 may be implemented in any known controller technology,including but not limited to a processor (PLC, CPU, DSP), FPGA, ASIC orany other suitable digital and/or analogue circuitry capable ofperforming the intended functionality.

Finally, the key device 1 has a memory 450 which is operativelyconnected to the processing unit 410. The memory 450 may be implementedby any known memory technology, including but not limited to E(E)PROM,S(D)RAM and flash memory, and it may also include secondary storage suchas a magnetic or optical disc. Physically, the memory 450 may consist ofone unit or a plurality of units which together constitute the memory450 on a logical level. In addition to storing various programinstructions and data for the various functions and applications whichare typically available in a mobile terminal, the memory 450 alsocomprises the program instructions 452 and work data for theaforementioned access control software application. Also, any updatedlock access data received in step 200 will be buffered in the memory450, as seen at 456.

With reference to FIG. 5, the lock device 40 generally comprises thefollowing main components. A processing unit 510 is overall responsiblefor the operation and control of the different components of the lockdevice 40. The processing unit 510 may be implemented in any knowncontroller technology, including but not limited to a processor (PLC,CPU, DSP), FPGA, ASIC or any other suitable digital and/or analoguecircuitry capable of performing the intended functionality.

The lock device 40 of this embodiment is a stand-alone, autonomouslyoperating device which requires no wire-based installations, neither forcommunication nor for power supply. Instead, the lock device 40 ispowered solely by a local power unit 520 which comprises one ore morelong-life batteries. It interacts with key devices, as alreadymentioned, by wireless activities. The lock device 40 therefore has aninterface 540 for short-range wireless data communication. In thedisclosed embodiment of FIG. 5, the interface 540 comprises a Bluetooth®transceiver, by means which the lock device 40 can communicate with, forinstance, the key device 1 over the Bluetooth® link 14. The Bluetooth®transceiver is assigned a unique Bluetooth® address LD_ID. Alternativelyor additionally, the interface 540 may for instance comprise transceivercomponents for IrDA, WLAN or NFC.

The lock device 40 of the disclosed embodiment further includes areal-time clock 530 capable of providing the processing unit 510 with anaccurate value of the current time. However, embodiments are alsopossible where no real-time clock is provided.

Finally, the lock device 40 has a memory 550 which is operativelyconnected to the processing unit 510. The memory 550 may be implementedby any known memory technology, including but not limited to E(E)PROM,S(D)RAM and flash memory, and it may also include secondary storage suchas a magnetic or optical disc. Physically, the memory 550 may consist ofone unit or a plurality of units which together constitute the memory550 on a logical level. The memory 550 serves to store various programinstructions and work data for functions to be performed by theprocessing unit 510 in order to carry out the tasks of the lock device40. For instance, these program instructions define a main accesscontrol module or means 552 which is responsible for the general partsof the lock device-side functionality shown in FIGS. 2, 3 a and 3 b.There is also a challenge generation module or means 554 (cf step 310,FIGS. 3 a-3 b), a challenge response verification module or means 556(cf step 340, FIGS. 3 a-3 b), an encryption/decryption module or means558, and a communication module or means 560 which handles allcommunication with key devices in cooperation with the interface 540.

Moreover, the memory 550 serves to store a local lock device database(LD-DB) 570, which includes lock access data 572 upon which the accesscontrol decisions are based (cf steps 230 and 250 in FIG. 2). The lockdevice database 570 may also store status and log file data which arereferred to further below (cf step 270 in FIG. 2). Also, the memory 550serves to store a challenge code 580 generated by the lock device, andin some embodiments also a plurality of additional challenge codes 582.The lock device 40 has a serial number which was assigned duringmanufacturing, assembly, delivery or installation. This serial number isalso stored in the memory 550, as seen at 590.

For further implementation details and possible additional components ofthe lock device 40, reference is made to the aforementioned WO2006/098690, which is fully incorporated herein by reference.

Referring back to step 210 in FIG. 2, when the user 2 has brought hiskey device 1 near the door 50 which is protected by the lock device 40,the user may request access by issuing a command in the user interfaceof the key device 1, e.g. by invoking a function in the aforementionedaccess control software application. In alternative embodiments, thismay instead occur automatically. For instance, if the lock device 40 hasaccess to the output signal of a presence sensor on or at the door 50,the lock device 40 may detect the presence of the user 2 and in responsetrigger performance of the remaining steps. As further alternatives, thekey device 1 or the lock device 40 may be configured to regularlytransmit beacon signals (e.g. Bluetooth® inquiries) which may bedetected and responded to by the other device.

In a following step 220, the lock device 40 will detect the key deviceidentifier KD_ID by reading, from the Bluetooth® communication trafficbetween the devices, the Bluetooth® address assigned to the Bluetooth®transceiver 440 in the key device 1. It is to be noticed that it is notnecessary to wait until a bidirectional Bluetooth® link has beenestablished in order to detect the Bluetooth® address of the key device1, since the Bluetooth® address is included in and can be read alreadyfrom the initial Bluetooth® messages which are sent between the devicese.g. during paging, handshaking and initiation.

Then, in a step 230, the lock device 40 will check if the detected keydevice identifier KD_ID matches the lock access data 572 currentlystored in its internal memory 550. If so, the lock device 40 considersthe key device 1 as a known key device and proceeds to an optional step240, in which further verification of the key device 1 may take place.Such further verification may include establishing and furthercommunicating over a bidirectional Bluetooth® link 14 between the lockdevice 40 and key device 1. For instance, the access control softwareapplication in the key device 1 may prompt the user to enter a PIN codeon a keypad of the key device 1, and the PIN code may be communicatedover the Bluetooth® link to the lock device 40, which may compare thereceived PIN code with a prestored PIN code associated with the keydevice identifier KD_ID in the lock access data 572. Alternatively oradditionally, the user 1 may provide some biometric data, such as ascanned fingerprint, by means of the key device 1, to be evaluated bythe lock device 40 upon receipt.

In a subsequent step 250, the lock device 40 determines whether or notthe key device 1/user 2 shall be granted access or not. This may involvechecking that the KD_ID of the key device 1 was recognized in step 230as a known KD_ID which is not included in a “black list” of blocked keydevice identifiers in the lock access data 572. If the optional step 240is applied, the determination in step 250 will also include a check thatthe further verification in step 240 was successful.

A favorable decision in step 250 will trigger a step 260 in which theactual access in made to happen. This may involve actuating an electricmotor to displace a lock plunger or other mechanism to an unlockedposition, or releasing a latch mechanism so that it will no longerprevent manual or automatic opening of the door 50. This is collectivelyreferred to as lock actuator 512 in FIG. 5.

Finally, an optional step 270 may be performed, in which further dataexchange may take place. This may involve transfer from the lock device40 to the key device 1 of the log file and status data recorded by thelock device regarding for instance previous attempts by key devices toaccess the protected environment. Additionally or alternatively, thefurther data exchange may involve transfer from the key device 1 to thelock device 40 of the updated lock access data 456 which was previouslyreceived in step 200, this updated lock access data being intended toreplace or upgrade the existing lock access data 572 in the local lockdevice database 570 held by the lock device 40 in its memory 550.

An unfavorable decision in step 250 will instead result in terminationof the procedure of FIG. 2, without any performance of step 260.

This far, the description of FIG. 2 essentially corresponds to thedisclosure in the aforementioned WO 2006/098690, in which the skilledperson will find any implementation details not explicitly mentioned inthe present patent application. The novel and inventive functionalitywill now be described.

In step 230, if the result of the check is that the detected key deviceidentifier KD_ID does not match the lock access data 572 currentlystored in the internal memory 550 of the lock device 40, this means thatthe key device 1 is unknown to the lock device 40. This situation willtrigger a challenge procedure which is shown in FIGS. 3 a and 3 b.

The main steps of the challenge procedure in FIGS. 3 a and 3 b are thefollowing. In step 310, a challenge is generated by the lock device 40.The generated challenge is based on the challenge code 580. Thechallenge code 580 may be generated by the lock device 40 “on the fly”,i.e. when needed for step 310, or in advance. The generated challengecode 580 is stored in the internal memory 550 of the lock device 40.

In step 320, the generated challenge is sent to the key device 1 overthe Bluetooth® link 14. The key device 1 will then either act inaccordance with a first mode of operation, which is referred to as“Online” throughout this document and which is illustrated in FIG. 3 a,or it will act in accordance with a second mode of operation, which isreferred to as “Offline” (FIG. 3 b). The Online mode typically applieswhen the key device 1 has momentary access to the communicationnetwork(s) 104 and therefore also to the administration server 100.Conversely, the Offline mode typically applies when the key device 1does not have momentary access to the communication network(s) 104 andtherefore cannot reach the administration server 100 for the time being.Particulars of the Online and Offline modes are described in more detailin later sections of this document, but these modes can be summarized inthe following way:

As seen in step 321 in FIG. 3 a, in the Online mode, the key device 1will forward the challenge to the administration server 100 over thecommunication network(s) 104, thereby in effect making a request for achallenge response. The administration server 100 will generate achallenge response in step 322, and send the generated challengeresponse to the key device 1 in step 323 over the communicationnetwork(s) 104. Upon receipt, the key device 1 will forward thechallenge response to the lock device 40 in step 324 over the Bluetooth®link 14.

In the Offline mode shown in FIG. 3 b, there will be no communicationwith the administration server 100 at the moment in time when steps 310and 320 are performed (i.e. when the key device 1 has approached thelock device 40 and requests access). Instead, at some earlier point intime, the user 2 of the key device 1 will make a request over thecommunication network(s) 104 for a pre-generated challenge response fromthe administration server 100 (step 301). In response, theadministration server 100 will generate the challenge response in step302, using in this case a previously stored copy of a valid challengecode for the lock device 40. This copy will have been generated inadvance by the lock device 40 (e.g. already during the manufacturing ofthe system, i.e. prior to delivery and installation), and communicatedto the administration server 100 for storage in the system database 102.

The pre-generated challenge response is sent to the key device 1 in step303 over the communication network(s) 104. Upon receipt, the key device1 will store the pre-generated challenge response in its internal memory450 in step 304, as seen at 454 in FIG. 4. In alternative embodiments,the pre-generated challenge response may be created and sent to the keydevice 1 on the administration server's 100 own initiative, rather thanin response to a request from the key device 1.

Later on, when the lock device 40 sends the generated challenge to thekey device 1 over the Bluetooth® link 14 in step 320, the key device 1will react in step 325 by retrieving the stored pre-generated challengeresponse from location 454 in its internal memory 450. Then, the keydevice 1 will send the pre-generated challenge response to the lockdevice 40 in step 326 over the Bluetooth® link 14.

One important feature of the challenge response (in Online mode as wellas Offline mode) is that it, in some way, is based on (e.g. is afunction of, or otherwise depends on or reflects) the key deviceidentifier of the key device 1. In a particularly advantageousembodiment, the remote administration server 100 keeps a copyKD_ID_(admin) _(—) _(copy) of each key device identifier for the variouskey devices 1 ₁-1 _(m), 1′₁-1′_(m), in the system (e.g. by storing suchcopies in the access control system database 102 or other parts of itsmemory). When generating the challenge response in step 322 or 302, theadministration server 100 will read and use this copy KD_ID_(admin) _(—)_(copy) of the key device identifier for the particular key device 1.

In step 330, the lock device 40 will use the Bluetooth® link 14 toreceive the challenge response from the key device 1. Then, in step 340the lock device 40 will verify the received challenge response basedprimarily on i) the challenge code 580 which is stored in the internalmemory 550 of the lock device 40, and ii) the key device identifier ofthe key device 1. This is handled by the processing unit 510 which willinvoke the challenge response verification means 556. In theparticularly advantageous embodiment mentioned above, the lock device 40will detect the key device identifier KD_ID of the key device 1sometimes during the Bluetooth® communication between lock device 40 andkey device 1, i.e. for instance in step 220, 320 or 330. The lock device40 will use the detected key device identifier KD_ID for verifying thereceived challenge response in step 340. This is a security advantage,since the challenge response (as generated by the administration server100) is based on a remotely stored copy of the key device identifier,whereas the verification of the challenge response by the lock device 40will be based on the “real” key device identifier as detected duringactual communication with the key device. Therefore, a malicious attemptto use another key device than the one that is the rightful owner of thekey device identifier KD_ID is likely to be detected in the verificationstep 340. A favorable output or result from the verification step340/challenge response verification means 556 is therefore issued whenthe lock device 40 concludes that the challenge response is as expectedand that, conclusively, the administration server 100 has approved thatthe key device 1 shall be given access to the lock device 40.

In step 350, the lock device 40 determines—based on the output of theverification step 340/challenge response verification means 556—whetheror not the key device 1 can be regarded as trusted, even though the keydevice 1 was a priori unknown to the lock device 40. Therefore, in caseof a favorable verification result in step 340, the execution willcontinue to node (B) in FIG. 2, whereupon the optional furtherverification of the key device 1 may take place in step 240, followed bythe access determination step 250, lock actuation step 260 and furtherdata exchange step 270. In other words, a key device 1 which is a prioriunknown to a lock device may prove its trustiness by presenting to thelock device 40 a challenge response that the lock device relies on.

On the other hand, in case of a negative verification result in step340, the execution in step 350 may cause the key device 1 to be blockedfrom further access to the lock device 40. This may be done by storingthe key device identifier KD_ID of the key device 1 in a black list inthe lock access data 572. A key device which has been blocked by a lockdevice may then require an unblocking event brought about by anambassador device to the lock device, for the key device to be removedagain from the black list.

Some of the key steps of the mode referred to as Online above will nowbe described in more detail.

Lock Device—Generation of Challenge

The lock device 40 generates a challenge code 580 for use in step 310 inFIGS. 3 a and 3 b by invoking the challenge generation module 554. Thechallenge code 580 may be generated as an n-bit random number using arandom number algorithm where the seed is a timer value (e.g. fromreal-time clock 530), some part of the log file and status data recordedin the local lock device database 570, etc. In one embodiment, n=256.

Lock Device—Encryption of Challenge

For enhanced security in the access control system, the communicationbetween lock device 40 and administration server 100 is encrypted by thesender and decrypted by the receiver. As regards the lock device 40, theencryption/decryption module 558 handles this by applying anencryption/decryption algorithm or standard which is known also to theadministration server 100. One embodiment applies AES (AdvancedEncryption Standard), using an encryption/decryption key which is basedon a standard function known as SHA256 (Secure Hash Algorithm 256). Inmore detail, the encryption/decryption key is calculated as the outputof SHA256(Algorithm1(serial No 590, LD_ID)), where Algorithm1 should beknown only to the administration server and the lock devices in thesystem. The challenge sent in step 320 is then generated byAES-encrypting the generated challenge code with theencryption/decryption key.

Using both the lock device serial number 590 and the lock deviceidentifier LD_ID (i.e. the unique Bluetooth® address of the lockdevice's Bluetooth® transceiver 540) represents a high level ofsecurity, since both of these parameters are very unlikely to be knownby anyone else but the administration server 100. However, otherembodiments may use just one of the lock device serial number 590 andthe lock device identifier LD_ID for the calculation of theencryption/decryption key.

Administration Server—Decryption of Challenge

When key device 1 forwards the challenge to the administration server100 in step 321, the access control software application 452 in the keydevice 1 will also provide sufficient information for the administrationserver 100 to determine the lock device from which the challengeoriginated (in this case lock device 40) and to which the challengeresponse therefore is to be directed. The administration server 100 willsearch the system database 102 and retrieve further information aboutthe lock device 40. This further information includes the serial numberand the lock device identifier of the lock device 40, and it will beused by the administration server 100 to calculate anencryption/decryption key as the output of SHA256(Algorithm1(retrievedlock device serial number, retrieved lock device identifier)). Theadministration server 100 will then decrypt the received challenge byapplying the same encryption/decryption algorithm (AES) as the lockdevice 40 did, using the calculated encryption/decryption key. Thus,this decryption will derive the challenge code. Of course, inembodiments which use only one of the lock device serial number and thelock device identifier for the encryption/decryption key at the lockdevice side, the same will apply to the administration server side.

Administration Server—Generation of Challenge Response

Then, the administration server 100 will generate the challenge responsein step 322. The challenge response chlg_resp_(—)1 will be generated byusing an Algorithm2 which should be known only to the administrationserver and the lock devices in the system. The input parameters ofAlgorithm2 include the challenge code and the key device identifier ofkey device 1. As already explained in conjunction with FIG. 3 a above,the key device identifier of the key device 1 will be given by searchingthe system database 102 and retrieving the copy KD_ID_(admin) _(—)_(copy) of the key device identifier for key device 1. Sufficientinformation for this database search will be provided by the accesscontrol software application 452 in the key device 1 in step 321. Sincethe user 2 will have logged in to the software application 452, hisidentity will be known. By keeping in the system database 102 across-reference list between user login identities and corresponding keydevice identifiers, the correct copy KD_ID_(admin) _(—) _(copy) can beretrieved in step 322 by the administration server 100. To this end, theserver 100 will make a check that the user 2 is authorized to access thelock device 40 according to data in the system database 102 whichdefines the conditions under which individual ones of the key devicesmay be granted access to environments 50 protected by individual ones ofthe lock devices in the access control system.

Advantageously, the generated challenge response also depends on thelock device identifier, LD_ID, of the lock device 40, as found in thesystem database 102. In other words, an additional input parameter ofAlgorithm2 may be the lock device identifier.

In addition, the generated challenge response may include usagerestriction data. The usage restriction may include an expirationdate/time which defines the date/time when the challenge response may beused at the latest by a key device seeking access to a lock device, or alimit on the maximum number of times the challenge response may be usedby a key device, or both.

Particularly for embodiments where the lock device does not include areal-time clock 530 (thereby preventing the lock device 40 fromevaluating a usage restriction in terms of an expiration date/time), thegenerated challenge response may include a part which is based on thekey device identifier KD_ID of the key device 1. This will allow thesoftware application 452 in the key device to check the receivedchallenge response in step 324 for any usage restriction includedtherein, and use its own real-time clock (or a network-based clockservice) to determine whether the expiration date/time has lapsed. Ifso, the challenge response will not be forwarded by the key device 1 tothe lock device 40. Since the encryption/decryption algorithm and keyshould not be known to intermediate devices like the key device 1, thispart of the generated challenge response should only depend on the keydevice identifier KD_ID, which of course, is known to the key device 1.

Administration Server—Encryption of Challenge Response

The generated challenge response is encrypted by applying AES, using anencryption/decryption key calculated from SHA256(Algorithm3(lock deviceserial No, LD_ID)), where Algorithm3 should be known only to theadministration server and the lock devices in the system. Algorithm3 maybe identical to or different from Algorithm1. The encrypted challengeresponse is sent to the key device 1 in step 323, as previouslyexplained.

Lock Device—Decryption of Challenge Response

When the lock device 40 receives the challenge response in step 330, itwill decrypt it by applying the same encryption/decryption algorithm(AES) and using the same encryption/decryption key as was used by theadministration server 100. Thus, the encryption/decryption module 558will apply AES, using an encryption/decryption key calculated fromSHA256(Algorithm3(serial No 590, LD_ID)). The decryption will reveal thechallenge response chlg_resp_(—)1 as generated by the administrationserver 100.

Lock Device—Verification of Challenge Response

In step 340, the challenge response verification module 556 will beinvoked to verify the decrypted challenge response. Algorithm2 will beexecuted, with input parameters (challenge code 580, LD_ID, KD_ID) andoutput chlg_resp_(—)2. The challenge code 580 will be read from theinternal memory 550, and LD_ID is available from the interface 540.KD_ID has, as already explained, been detected by the lock device 40sometimes during the Bluetooth® communication between lock device 40 andkey device 1, e.g. in any of the prior steps 220, 320 or 330. In otherwords, the lock device 40 produces a candidate challenge responsechlg_resp_(—)2 by executing Algorithm2.

A verification result is issued in step 340 by comparing the received(and decrypted) challenge response chlg_resp_(—)1 and the candidatechallenge response chlg_resp_(—)2. These two instances of the challengeresponse have been generated by the administration device and by thelock device, respectively. If they match, this means that the key device1 has been appropriately approved by the administration server 100 forthe lock device 40 in question, even though the key device 1 was apriori unknown to the lock device 40. Therefore, in case of a match, afavorable result is issued from the verification step 340.

Now, some of the key steps of the mode referred to as Offline above willnow be described in more detail. Only differences with respect to theOnline mode will be described.

Lock Device—Generation of Challenge Codes

In order to support offline mode, the lock device 40 will in advancegenerate a number of challenge codes 580, 582, using the proceduredescribed above. These challenge codes will be stored in memory 550 andwill moreover be communicated to the administration server 100 forstorage in the system database 102. The challenge codes may becommunicated already during the manufacturing of the system, i.e. priorto delivery and installation. Alternatively, they may be generated bythe lock device 40 at some prior moment in time and communicated to theadministration server 100 via an ambassador key device when visiting thelock device.

Administration Server—Generation of Challenge Response

There is of course no need for the administration server 100 to decrypta challenge received from the key device, since no challenge will begenerated by the lock device 40 in offline mode. Instead, whengenerating the challenge response in step 302, the administration server100 will retrieve any of the previously stored challenge codes relatingto lock device 40 from system database 102.

A challenge code may typically only be used once. Therefore, when theadministration server notices that there is for instance only 1 or 2unused challenge codes left in the system database 102 for a particularlock device, it may send an alert via an ambassador key device to thelock device in question. Sooner or later, when the lock devicecommunicates with this ambassador key device in step 270, it may readthis message and return with new generated challenge codes which arecommunicated back to the administration server 100 by the ambassador keydevice. Alternatively, the lock device may itself keep track of thenumber of unused challenge codes 580, 582 and generate new challengecodes as appropriate.

Lock Device—Verification of Challenge Response

In this case, the lock device 40 will not know for sure which particularchallenge code 580, 582 that was used by the administration server 100for generating the challenge response. Therefore, the lock device 40 maytest the received (and decrypted) challenge response by executingAlgorithm2 for all challenge codes 580, 582 to produce a candidatechallenge response chlg_resp_(—)2_(i) for each challenge code, where i=1. . . [No of challenge codes]. If any of these candidate challengeresponse chlg_resp_(—)2_(i) results in a match with the receivedchallenge response chlg_resp_(—)1, a favorable result may be issued fromthe verification step 340.

1-15. (canceled)
 16. A lock device for use in an access control systemwhich involves a plurality of lock devices, a plurality of key devices,each key device having a key device identifier, and an administrationserver having an associated system database which defines the conditionsunder which individual ones of the key devices may be granted access toprotected environments by individual ones of the lock devices, the lockdevice comprising: a transceiver for short-range wireless communicationwith a key device among said plurality of key devices; a memory; and aprocessing unit, the processing unit being configured for: detecting thekey device identifier of said key device during the short-range wirelesscommunication with the key device; generating a challenge code to bestored in said memory; generating a challenge based on said challengecode; causing said transceiver to send the generated challenge to saidkey device; receiving, via said transceiver, a challenge response fromthe key device, wherein the challenge response originates from theadministration server; verifying the received challenge response basedon the challenge code in said memory and on the detected key deviceidentifier of said key device; and determining whether conditionalaccess may be given to the key device based on an output from said meansfor verifying.
 17. The lock device as defined in claim 16, wherein theprocessing unit is configured for generating the challenge by encryptingthe challenge code using a key which is based on at least one of aserial number and a lock device identifier of said lock device.
 18. Thelock device as defined in claim 16, wherein the processing unit isconfigured for: receiving, via said transceiver, an encrypted challengeresponse from the key device; and decrypting the received encryptedchallenge response by using a key which is based on at least one of thelock device serial number and the lock device identifier of said lockdevice.
 19. The lock device as defined in claim 16, wherein the memoryis for storing of lock access data, said lock access data including keydevice identifiers of key devices which are allowed to access theenvironment protected by the lock device, and wherein the processingunit is configured for: when the key device approaches the lock deviceand seeks access, detecting the key device identifier for the keydevice; checking if the detected key device identifier matches the lockaccess data stored in the memory; and if no match is found, generatingsaid challenge and causing sending of the generating challenge to thekey device.
 20. The lock device as defined in claim 16, the short-rangewireless communication being Bluetooth® communication, wherein theprocessing unit is configured for detecting the key device identifier byreading a Bluetooth® address assigned to a Bluetooth® transceiver usedby the key device for the Bluetooth® communication with the lock device.21. An administration server for use in an access control system whichfurthermore includes a plurality of lock devices and a plurality of keydevices, each key device having a key device identifier, theadministration server having a system database associated therewith,wherein the system database defines the conditions under whichindividual ones of the key devices may be granted access to protectedenvironments by individual ones of the lock devices, and theadministration server being configured for: receiving a challenge from akey device among said plurality of key devices over a communicationnetwork, wherein the challenge originates from a lock device, among saidplurality of lock devices, to which the key device has sought access;retrieving a copy of the key device identifier of said key device bysearching the system database using information received from the keydevice; deriving a challenge code from the received challenge;generating a challenge response based on the derived challenge code andthe retrieved copy of the key device identifier; and sending thegenerated challenge response to said key device over said communicationnetwork.
 22. The administration server as defined in claim 21, furtherbeing configured for: receiving the challenge from the key device;determining, from information received from the key device, the lockdevice from which the challenge originated; searching the systemdatabase associated with the administration server to retrieve at leastone of a serial number and a lock device identifier of the lock devicefrom which the challenge originated; and decrypting the receivedchallenge to derive the challenge code using a key which is based on theretrieved serial number and/or lock device identifier.
 23. Theadministration server as defined in claim 22, further being configuredfor: encrypting the challenge response by using a key which is based onthe retrieved serial number and/or lock device identifier; and sendingthe encrypted challenge response to the key device.
 24. Theadministration server as defined in claim 21, wherein the challengeresponse generated by the remote administration server includes usagerestriction data, defining at least one of an expiration date/time forthe challenge response, and a maximum usage limit for the challengeresponse.
 25. The administration server as defined in claim 21, whereinthe challenge response generated by the remote administration serverincludes a part which is readable by the key device and which defines anexpiration date/time for the challenge response, said part of thechallenge response serving to cause the key device to prevent forwardingof the challenge response to the lock device if the expiration date/timehas lapsed.
 26. An access control system which comprises a plurality oflock devices, a plurality of key devices, each key device having a keydevice identifier, and an administration server having an associatedsystem database which defines the conditions under which individual onesof the key devices may be granted access to protected environments byindividual ones of the lock devices, wherein each lock device comprises:a transceiver for short-range wireless communication with a key deviceamong said plurality of key devices; a memory; and a processing unit,the processing unit being configured for: detecting the key deviceidentifier of said key device during the short-range wirelesscommunication with the key device; generating a challenge code to bestored in said memory; generating a challenge based on said challengecode; causing said transceiver to send the generated challenge to saidkey device; receiving, via said transceiver, a challenge response fromthe key device, wherein the challenge response originates from theadministration server; verifying the received challenge response basedon the challenge code in said memory and on the detected key deviceidentifier of said key device; and determining whether conditionalaccess may be given to the key device based on an output from said meansfor verifying.
 27. The access control system as defined in claim 26,wherein the administration server is configured for: receiving thechallenge from the key device over a communication network; retrieving acopy of the key device identifier of the key device by searching thesystem database using information received from the key device; derivinga challenge code from the received challenge; generating a challengeresponse based on the derived challenge code and the retrieved copy ofthe key device identifier; and sending the generated challenge responseto the key device over the communication network.
 28. The access controlsystem as defined in claim 26, wherein the processing unit of the lockdevice is configured for: generating, in advance, one or more challengecodes, storing the generated one or more challenge codes in localmemory, and communicating the generated one or more challenge codes tothe administration server for storage in the system database; whereinthe key device is configured for: requesting and receiving, in advance,a pre-generated challenge response from the administration server, andstoring the received pre-generated challenge response in local memory;wherein the administration server is configured for: retrieving any oneof the one or more challenge codes of the lock device from the systemdatabase, and using the retrieved challenge code when generating therequested pre-generated challenge response to be sent to the key device;and wherein the key device is configured, when approaching the lockdevice and seeking access, and being requested by the lock device toprovide a challenge response, for: responding by retrieving thepre-generated challenge response from local memory, and sending theretrieved pre-generated challenge response to the lock device.
 29. Theaccess control system as defined in claim 28, wherein the processingunit of the lock device is configured for: verifying the receivedchallenge response by producing a candidate challenge response from eachchallenge code stored in its local memory and the key device identifierof said key device, and matching the received challenge response againstall produced candidate challenge responses.